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METHOD AND SYSTEM FOR ISSUING 
INSURANCE UNDERWRITING INSTRUMENTS 



Related Application 

This application claims priority under 35 U.S.C. §1 19(e) of commonly 
assigned, United States provisional patent application serial no. 60/171,177, filed 
on December 16, 1999, entitled "METHOD AND APPARATUS FOR ISSUING 
INSURANCE POLICIES ONE STEP SURETY", the entire disclosure of which 
is hereby incorporated by reference 



Field of Invention 

The present invention relates to a method and system for completing 
insurance application forms, and more particularly to an automated system 
offering the capability to quote, issue and modify surety bonds and fidelity 
1 5 policies via a global telecommunication network such as the Internet. 

Background of Invention 

Underwriting insurance policies can be a complex and time consuming 
process. Many variables are considered in recognizing and qualifying the risks 
20 associated with underwriting a particular insurance policy, such as the location of 

the insured party and the reason for that policy. In particular, with respect to 
fidelity policies and surety bonds, the location of the particular job to be insured 
as well as the total contract amount of the project are typically important factors 
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in setting premium rates. Different localities, such as different states often have 
different premium rates. Also, different areas within a state can carry different 
levels of risks associated with construction projects, for example. 

Because of the many types of businesses and contracts that fidelity 
5 policies and surety bonds can be used to provide against loss for, the myriad 

variety of different forms required for underwriting such policies and the types of 
information needed to complete these forms makes the underwriting process a 
time intensive and complex one. 

In the case of a fidelity policy for example, the type of business that is to 
H 10 be insured (whether it be a small business or a large corporation), the number of 

; : i employees, as well as the location of that business, among other factors, are taken 

r \'i into consideration when quoting and providing a fidelity policy which will cover 

s burglary and fire insurance for that business. Additional factors that can affect the 

fjj premium amount for such a policy, such as past claims, are also taken into 

15 consideration when a fidelity policy underwriter is determining whether or not to 

• ^ issue such a policy to a prospective client. 

In the case of a surety bond for example, such as when guaranteeing the 
performance of a construction contract, the type of building to be constructed, the 
area where it is to be constructed and the number of people working on that 
20 contract within a given time period are all relevant factors to be investigated by 

the bond underwriters. Again, different types of contracts require different types 
of surety bond form applications which must be selected correctly in order to 
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adequately underwrite the bond and determine what the costs or premium of that 
bond will be. As the former tends to continually change over time, an insurance 
agent typically must periodically update his inventory of blank forms, discarding 
those that have been changed or superceded, 
5 For these reasons, many insurance underwriters have opted not to 

underwrite fidelity policies or surety bonds, because of the complexities involved. 
For example, these types of policies require complex risk rating methodologies, 
non-standard contract terms and conditions, and using specialized legal 
documents such as Powers of Attorney, which must accompany the underwriting 

10 contract. Accordingly, there is a need for a system and method whereby fidelity 

policies and surety bonds can be quickly and accurately completed, and wherein 
risks are adequately and completely analyzed and considered in setting the 
insurance premium price. 

It is therefore an object of the present invention to provide an automated 

1 5 system for generating underwriting policy contracts for the insurance industry. 

It is a further object of the present invention to provide an automated 
system which will present to fidelity and surety underwriters a database of forms 
needed to complete the underwriting process, which forms are available over a 
global telecommunication network such as the Internet. In this manner, 

20 underwriters do not need to separately and individually maintain a library of ever- 

changing forms since they are to be located in a central storage means such as a 
web server. 
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Summary of Invention 

A method for issuing an insurance underwriting instrument using at least 
one computing processor, the method including: identifying data stored in a 
plurality of memory locations and being indicative of a select one of a plurality of 
5 customers; receiving data indicative of an insurance instrument to be associated 

with the select customer; automatically calculating at least one rate associated 
with the insurance instrument using the data indicative of the customer and data 
indicative of the insurance instrument; selecting at least one of a plurality of 
forms for the insurance instrument using the data indicative of the insurance 
10 instrument; and, automatically rendering the at least one form using the at least 

one rate, the data indicative of the customer, and data indicative of the insurance 
instrument; wherein, the calculating and rendering are performed using the at least 
one computing processor. 

15 Brief Description of the Drawings 

Various other objects, features and advantages of the invention will 
become more apparent by reading the following detailed description in 
conjunction with the drawings, which are shown by way of example only, 
wherein: 

20 Figure 1 is a functional diagram of a technical architecture of various 

components according to one aspect of the present invention; 
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Figure 2 is a screen display of a main menu screen for issuing an insurance 
underwriting instrument according to an aspect of the present invention; 

Figure 3 illustrates a display showing examples of various types of surety 
bonds a user may select according to one aspect of the present invention; 
5 Figures 4A and 4B illustrate displays for entering bond selection and 

rating criteria after the type of surety bond has been selected from Figure 3 
according to an aspect of the present invention; 

Figure 5 illustrates a display for identifying a bond form to use for the 
issued insurance underwriting instrument according to an aspect of the present 
1 0 invention; 

Figure 6 illustrates a display for entering principal and obligee information 
for the selected bond according to an aspect of the present invention; 

Figure 7 illustrates a display for entering surety underwriting information 
for the selected bond according to an aspect of the present invention; 
15 Figure 8 illustrates a display for performing an underwriting check 

according to an aspect of the present invention; 

Figure 9 illustrates an underwriting check override screen according to an 
aspect of the present invention; 

Figure 10 illustrates a display for inputting premium calculations for the 
20 selected bond according to an aspect of the present invention; 

Figure 1 1 illustrates a display for communicating calculated billing terms 
according to an aspect of the present invention; 
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Figure 12 illustrates a display for inputting billing information for the 
selected bond according to an aspect of the present invention; 

Figure 13 illustrates a display for inputting additional information to be 
included on the selected bond according to an aspect of the present invention; 

Figure 14 illustrates a display for communicating a bond summary and for 
selecting ones of the selected forms to view according to an aspect of the present 
invention; 

Figure 15 illustrates an exemplary power of attorney issued by a system 
according to an aspect of the present invention; 

Figure 16 illustrates an exemplary general bond form issued by a system 
according to an aspect of the present invention; 

Figure 17 illustrates an exemplary invoice issued by a system according to 
an aspect of the present invention; 

Figure 18A illustrates a display showing examples of various types of 
fidelity policies a user may select according to an aspect of the present invention; 

Figure 1 8B illustrates a display for entering insured information according 
to an aspect of the present invention; 

Figure 18C illustrates a display for performing an underwriting check for a 
fidelity policy according to an aspect of the present invention; 

Figure 18D illustrates a display for performing a fidelity underwriting 
review according to an aspect of the present invention; 
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Figure 19 illustrates a display for inputting quote information of a fidelity 
policy according to an aspect of the present invention; 

Figure 20 illustrates a display for selecting and confirming a quote 
selection for a fidelity policy according to an aspect of the present invention; and, 

Figure 21 illustrates a flowchart showing the steps utilized in underwriting 
a surety bond or fidelity policy according to an aspect of the present invention. 

Detailed Description of a Preferred Form of the Present Invention 

Referring now to the drawings in detail, there will be described herein a 
preferred embodiment for a system to automatically quote, issue and modify 
insurance instruments such as surety bonds and fidelity policies via a global 
telecommunication network such as the Internet. While specific embodiments 
will be discussed herein, it will be readily appreciated by those skilled in the art 
that various modifications and alternatives to the embodiments described herein 
will fall within the scope of the invention. For sake of clarity, like references 
within various ones of the Figures identify like elements of the invention. 

As shown in Figure 1, the technical architecture of a system 10 according 
to a preferred form the present invention preferably includes four (4) primary 
layers: user interface layer 100; application logic layer 200; business logic layer 
300; and database management layer 400. Each layer 100, 200, 300, 400 is 
designed to perform various functions of the policy preparation process in a 
manner which facilitates the preparation of insurance underwriting instruments 




such as surety bond and fidelity policy documents by agents, i.e. users, as well as 
providing a potential customer with a quick and easy summary of the insurance 
needs and premiums that it will need to evaluate in order to accept such a policy. 

The user interface layer 100 includes a common web browser such as 
5 Microsoft Internet Explorer™ or Netscape Navigator™ being communicable with 

the application logic layer 200 via a computer network such as the global 
interconnection of computers and computer networks commonly referred to as the 
Internet, using a document viewer such as Adobe Acrobat™, and the web 
browsers' e-mail client. The application logic layer 200 comprises functionality 

10 associated with serving web pages and presentation logic. The business logic 

layer 300 comprises components that execute computational or database intensive 
logic, such as for selecting forms, rendering forms and conducting rating and 
premium calculations. The database management layer 400 comprises three 
components: a forms library 410, a policy database 420, and external interfaces 

15 430 to other insurance underwriting programs such as CAPIS, a new premiums 

processing system (NPPS) and TABS. CAPIS, as used herein refers to a program 
used to maintain agent records, NPPS as used herein refers to a program used to 
maintain premiums records, and TABS as used herein is a billing system. Using 
the system 10 comprising the functional layers 100, 200, 300 and 400, an 

20 insurance agent, i.e. user, utilizes screen displays generated to input information 

needed to prepare a surety bond or a fidelity policy for a customer. 
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In order to more fully define the operation of the system 10 according to a 
preferred form of the present invention, each of the functional layers 100, 200, 
300 and 400 described above will be more fully explained. 

In the user interface layer 100, a common web browser such as Netscape 
5 Navigator™ or Microsoft Internet Explorer™ running on a suitable 

microprocessor based device 110 such as a personal computer utilizing a suitable 
operating system such as Microsoft Windows™ for example, can be used to 
provide users, or agents, with access to the system 10 according to the present 
invention. Interactions between an agent and the system 1 0 can be done through a 

10 keyboard, mouse and suitable display device coupled to the device 110 for 

example. The user interface layer 100 thus controls the system 10 interface with 
the agents, e.g. applications screens, views and prints bond forms, and sends and 
receives e-mail messages from the underwriter to the agent for example. Thus, 
the user interface layer 100 presents the user with system screen images relevant 

15 to the user's task at hand. In order to control user access and functionality the 

system 10 requests from each user or the agent requesting access, a valid user 
identification password which must be entered to access his or her information. 
Preferably, interactions between the agent and the system 10 via the interface 
layer 100 of the present invention are secured using suitable encryption 

20 methodology as is well known in the art, such as Secure Socket Layer (SSL) 

technology, for example. 
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In addition to supporting a policy maintenance function, the user interface 
layer 100 preferably also provides a number of functions for bond forms. 
Specifically, the user interface layers 100 enables viewing and printing of forms 
generated from the forms library 410. Preferably the web browser running on the 
5 device 110 works in conjunction with a commercially available document 

viewing program also running on the device 110, such as Adobe Acrobat 
Reader™, to enable a user to zoom into particular areas of the form, scroll up and 
down between pages of the form, and to view directly any portion of completed 
bond form, for example. 

10 Preferably, the user interface layer 100 also provides for electronic mail 

(e-mail) capabilities between an agent and an underwriter for example. By 
configuring the agent's web browser running on a device 110 to access e-mail 
server 240 via any suitable communications medium, such as a direct telephone 
link, or via the Internet for example, an agent may send and receive e-mail via the 

15 system 10. Through this capability, an agent may send an e-mail message to the 

underwriter staff member or to another agent with an e-mail account on the 
system 10, to enable the timely exchange of information. Additionally, a staff 
member of the underwriter can send an e-mail directly to an agent so as to answer 
questions the agent may have about the particular policy, for example. The user 

20 interface layer 100 communicates with and passes user requests to the application 

logic layer 200. 
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The application logic layer 200 defines and controls the flow of a users' 
interaction with the system 10. This layer 200 handles user requests received 
from the user interface layer 100. In order to respond to those requests that 
require complex database access or resource intensive processing, such as forms 
5 rendering and premium calculations for example, the application logic layer 200 

forwards these request to the business logic layer 300, as described hereinafter, 
for additional processing. In addition, the application logic layer 200 utilizes 
webservers 210, 220, 230 and 240 and policy maintenance application 250. By 
way of example, webservers 210^ 230 and 240 receive requests from and transmit 

10 responses to the user interface layer 100 via enterprise server 220. The 

Application logic layer 200 also includes with user management component 235 
for providing access control services which maintain user logins, access control 
and electronic mail directory information. E-mail component 245 provides 
mailboxes so that the user interface layer 100 may send and receive e-mail, and 

15 also integrates with the user management component 235 for directory services. 

The policy maintenance application 250 provides correct sequences of the surety 
system display screens and navigates the user through these screens. 

In a preferred embodiment of the present invention, the web servers 210, 
220, 230, 240 incorporate a Netscape Enterprise Server™ 220 running in two 

20 modes: unsecured mode (HTTP for example) and secured mode (HTTPS for 

example). Preferably, unsecured server functionality is used only in very limited 
_ situations, such as when a user is first logging onto the system 10 or requires 
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access to help screens, using a device 110 as has been discussed with regard to 
user interface layer 100, for example. Secure server functionality supports 
encrypted transmission with the user, preventing unauthorized parties from 
obtaining knowledge of the system processing or policy holder information. 
5 Directly accessible via the Internet for example, the web servers 210, 220, 230, 

240 are the primary interfaces for users/agents submitting requests to the system 
10 via the user interface layer 100, e.g. using devices 110. Whether a request is to 
rate a new policy, change an endorsement, or generate a completed bond form for 
example, the web servers 210, 220, 230, 240 respond to requests submitted 
Z"10 through a user's browser running on a device 110. While the servers 210, 220, 

f ~- 230, 240 do not implement the key business functions required for operation of 

f !j the system 10 according to an aspect of the present invention, they do route these 

- requests appropriately as is well understood. The server 220 preferably includes 

l y an unsecured directory 222 accessible via the unsecured mode and a secured 

^!1 5 directory 224 accessible via the secured mode. 

The user management component 235 operates in tandem with web server 
230, and with electronic mail component 245 respectively operating in tandem 
with web server 240, and with the policy maintenance application 250, to 
authenticate users and to control access through restricted system 10 functionality. 
20 This component 235 provides the capabilities to define user roles. For example, 

user roles can be created to differentiate Account Service Representatives (ASRs) 
from producers, e.g. agents. The user management component 235 also 
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preferably provides a directory for the email component 245. This directory 
identifies an e-mail box location for each user. 

Electronic mail component 245 serves to enable users to exchange email 
messages within the insurance underwriting system 10 of the present invention, in 
5 conjunction with Netscape Messaging Server™ 240. It also provides the ability 

to send e-mail directly from the system 10 for example, for an agent to contact the 
insurance underwriter with a question by clicking on an appropriate icon on the 
screen with the aforementioned agent's mouse or other suitable pointing device 
coupled to the device 1 10 as is well understood. 

10 Systems management and monitoring component 215 operates in tandem 

with web server 210 and provides a system operator with conventional tools for 
determining whether the system 1 0 is running smoothly, by analyzing diagnostic 
information for servers 210, 220, 230, 240. Using a set of visual clues to indicate 
warnings and trouble signs, a system operator, or administrator, can quickly 

15 determine whether a problem exists and diagnose potential causes. 

The policy maintenance application 250 preferably contains application 
logic for displaying a navigating screen on a device 110 and hence to a user, 
including those specific to a Piece Of Business (POB) such as a particular fidelity 
policy or surety bond that the agent has prepared. The policy maintenance 

20 application 250 applies basic logic and validations, as in the case of determining 

whether all underwriter questions have been answered in the affirmative. Thus, 
the policy maintenance application 250 of the system 10 supports activities such 
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as fidelity and surety bond issuance, policy changes, endorsement, cancellations 
and acceptance processing. While the policy management application 250 
contains the logic for managing these user interactions, the business logic layer 
300 preferably provides more computational and resource intensive services. 
5 The business logic layer 300 provides functions that require more 

intensive computer processing resources than application logic layer 200, and 
which may also require substantial scalability of the computing platform. The 
business logic layer 300 works closely with the application logic layer 200, with 
the result being that major fidelity and surety bond functions of the system 10 

10 according to the preferred form of the present invention are provided by the two 

layers 200, 300 working in combination. In general, if a user request is relatively 
simple in nature, it is handled directly by the application logic layer 200. 
However, the business logic layer 300 handles requests that require complex 
logic, extensive computations or intensive database accesses, for example. Thus, 

15 the business logic layer 300 preferably employs technologies that are efficient and 

precise for the software engineering of more complex algorithms. The business 
logic layer 300 preferably includes transaction processor 310, form select server 
320, forms rendering server 330, rating and premium calculation engine 340 and 
automatic renewal application 350. 

20 The transaction processor 310 transfers requests between business logic 

layer 300 components and the application logic layer 200. Requests for functions 
in the business logic layer 300 are sent through the transaction processor 310. 
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Much like the web servers 210, 220, 230, 240 for example, the transaction 
processor 310 does not directly perform business calculations or implement 
applicable business rules, but rather routes those tasks to the other components in 
the business logic layer 300 for more efficient processing. Preferably, 
5 commercially available software commonly known as TUXEDO is used for this 

processing. This allows each component to be monitored, and if one should fail, 
to automatically send a notification to the appropriate technical staff and 
automatically restart that component. TUXEDO, as used herein, is a 
commercially available transaction processing application available from BEA 

10 SYSTEMS. 

The forms select server 320 provides the ability to search the bond forms 
library 410 for an appropriate set of bond forms based on identified selection 
criteria. The policy maintenance application 250 collects data from user input, 
and sends the collected data to the forms select server 320. The bonds form 

15 library 410 is queried and searched for appropriate bond forms based upon the 

input criteria. The forms select server 320 implements the mechanism to select 
either one or more bond forms from a list of bond forms that match the selection 
criteria. 

The forms rendering server 330 provides functions to automatically "fill 
20 out" a bond form identified from the bond library 410 by the server 320. The 

policy maintenance application 250 passes the bond form name and information 
to the forms rendering server 330, which in turn generates the information 
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required to fill out the input fields on the retrieved bond form. When complete, 
the retrieved bond form and the data for the bond form are returned to the policy 
maintenance application 250, which sends this information to the user interface 
layer 100 so that the retrieved bond form including relevant data can be displayed 
5 or printed using a device 110. During operation of automatic renewal application 

350, the forms render server 330 can be used to fill out a bond form in a batch 
cycle without requiring the agent to again input identical information. 

The rating and premium calculation engine 340 executes logic and 
calculations required to rate policies and generate premiums. This component 

10 340 implements business rules defined in suitable rating spreadsheets for 

example. The policy maintenance application 250 sends rating variables to the 
rating and premium calculation engine 340 and the engine 340 returns the results 
of the calculation back to the policy maintenance application 250. 

The automatic renewal application 350 is responsible for automatically 

15 renewing policies. The automatic renewal process is scheduled to run at periodic 

intervals (such as nightly or weekly) by a systems administrator. Preferably 
automatic renewal will, according to automatic renewal selection criteria, select 
policies that are eligible for renewal in an upcoming time frame using 
conventional business logic. The automatic renewal application 350 then 

20 processes the renewal for the policies, calling upon the rating and premium 

calculation engine 340 as has been discussed. Additionally, the automatic 
renewal application 350 calls for the forms rendering server 330 to fill out the 
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appropriate bond form and print it on a network printer coupled to the system 10, 
for example. The automatic renewal application 350 has three outputs: a renew 
list of particular Pieces Of Business (POBS) that have been renewed; an 
underwriting list of particular Pieces Of Business (POBS) that require attention by 
5 the underwriter; and, an exception list which lists those policies which were not 

renewed due to an exception that occurred during processing. 

The fourth layer, the data management layer 400, provides services for 
restoring and retrieving information from the insurance underwriting system 10 of 
the present invention. Using the combination of preferably two databases, one for 

10 the forms library 410 and the other for the policy data 420, the data management 

layer 400 services requests for information from the policy management 
application 250 as well as the business logic layer 300. Additionally, data 
conversion processes 440 use the data management layer 400 to store converted 
information from legacy systems, e.g. remapped provided data. Finally, batch, 

15 programs 430 integrate the databases with external systems such as those 

described above. 

The forms library 410 preferably provides a repository for storing images 
of bond forms for the underwriter and other sureties. The forms library 410 
preferably maintains different versions of the same form, as forms tend to evolve 
20 and change over time, and services requests from other system components to 

retrieve bond forms from the library 410. In addition to storing the actual bond 
form images, the library 410 also maintains information describing where on 
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particular bond forms input fields are located. The forms rendering engine 330 in 
the business logic layer 300 uses this information to electronically fill out a bond 
form retrieved from the library 410 with data provided by policy database 420. 

The policy database 420 manages particular business data for active and 
5 historic policies stored using the system 10 of the present invention. The policy 

database 420 services requests from other system components to retrieve and 
store information reliably. 

The external systems interfaces 430 send and receive data to and from 
other processing systems. In a preferred embodiment, the interfaces 430 send 

10 data to the NPPS and TABS systems, and receive data from the CAPIS system. 

In batch mode, the present system 10 extracts Piece Of Business (POB) 
information from the policy database 420, maps the extracted data according to a 
provided specification, and sends the data to the external interfaces 430 for 
processing, e.g. by NPPS or TABS systems for example. Similarly, the system 10 

15 according to the present invention receives a file from CAPIS, formats it 

according to the layout of the policy database 420 and imports it into the policy 
database 420. 

Data conversion 440 refers to the process of transferring data from legacy 
systems into the present system 10 to enable processing of existing policies by the 
20 system 10. 

Referring now also to Figures 2 - 20, therein is illustrated exemplary user 
interface screens displayed by the user interface layer 1 00 using a device 110 for 
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example. When an agent requests access to the system 10, a main menu screen 
500, such as is shown in Figure 2, provides options regarding fidelity policies, or 
surety bonds forms to the agent or system user. Additionally, the agent or user 
can select to search the system for existing POBs or blank forms, reprint 
5 previously generated forms, copy previous POBs to generate new POBs, review 

items associated with that agent or user which were referred to an underwriting 
department, do bulk report generation, maintain account, user or agency 
information, allocate blocks of bonds or get general help information. 

Referring now also to Figure 3, if, for example, the user selects a surety 

10 bond, a second screen 510 such as is illustrated in Figure 3 is displayed which 

specifies types of surety bond that can be selected from a second general menu 
511. Referring now also to Figures 4A and 4B, the system 1 0 preferably prompts 
the user to enter basic information regarding the client or policy holder requesting 
the bond after which the specific type of bond form necessary can be selected 

15 using a screen 512. Based upon the information entered, the system 10, provides 

a screen 515 as shown in Figure 5, which include list of bond forms 520 based on 
the type of surety bond entered previously. Further, a user can select to utilize a 
form selected from the list 520, a form not found in the list 520, or indicate that 
no form is applicable using data tools 522. Thus, if a form is to be generated by 

20 the system 10, a preselected form corresponding to one of the choices identified in 

list 520 can be chosen, or a user can opt to find a form not found on the list 520 
by searching forms library 410 which is stored in the data management layer 400. 
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Since specific types of forms require specific information to be entered, 
once a form is selected from the list 520, or otherwise identified, the system 10 
prompts for any additional information necessary to complete the surety bond 
form as is illustrated by screens 530, 540, 550, 560 and 570 shown in Figures 6, 7, 
5 8, 9 and 10. One of the advantages of the present invention is that the same type 

of information need not be entered multiple times if it appears on more than one 
area of the selected form. The system 10 preferably automatically inputs that 
information into all the spaces in the form or forms requiring that information. 

Referring now also to Figure 1 1 , after the information required to prepare 

10 the bond form is completed, the system 10 provides a quote for underwriting the 

insurance instrument by automatically calculating the premium and transmitting 
that information to the agent through the website 200, 300, 400. This is illustrated 
in Figure 1 1 as screen 580. 

Referring now also to Figure 12, billing information is entered by the 

15 agent using a screen such as that illustrated as 590. Other relevant information 

that should appear on the printed insurance bond form can then be entered by an 
agent using a display 600 such as that illustrated in Figure 13. A notification 
summary page 610, such as that illustrated in Figure 14 can be used to provide an 
agent an opportunity to review each of the required forms for the bond, as well as 

20 an opportunity to view them individually or as a group. An exemplary power of 

attorney, general bond form and invoice such as those identified on screen 610 of 
Figure 14 are shown in Figures 15, 16 and 17 for sake of completeness. 
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Analogously, in order to quote a different insurance instrument such as a 
fidelity policy, the system 10 prompts the user to enter basic information and 
continues in analogous manner as is shown in Figures 18A - 18D. As shown in 
Figure 1 9, the system 1 0 then prompts the user for coverage and deductible limits 
5 for the insurance instrument to be quoted for the client using a display 700 for 

example. 

Referring now also to Figure 20, the premium is then calculated based on 
the choices entered and the system 10 provides a pricing summary on a screen or 
display 710 that shows the premium for the fidelity policy, preferably by type of 
1 0 coverage. In a preferred embodiment, the system 1 0 also offers additional quotes, 

such as two, at increased gradual limits for the deductible and coverage limits 
based on the original information provided. This summary can then be used by 
the agent as a quote to the customer or potential policy holder for providing the 
fidelity policy. 

15 In the event, for example, that the agent is discussing the policy directly 

with the customer, such as by telephone or with the customer present at the 
agent's office, at the time the fidelity information is being entered into the system, 
the agent can provide the quote directly to the customer who can then either 
accept or decline that policy. In the event that the client finds the quote 

20 acceptable, the agent can immediately issue a fidelity policy. Thus, the agent can 

continue on with the quote process to complete the booking of the policy and 
issue that policy to the client without having to wait several business days for a 
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response from the insurance underwriter. If the client is unsure of accepting that 
policy, the information can be saved in the system for later retrieval by the agent 
in the event that the client then decides to move forward with the policy, at which 
time the agent can then continue with the booking and issuance of the fidelity 
5 policy without having to re-enter the basic information. 

Once the client has selected a particular fidelity policy the system 10 then 
calculates the premium and the agent can finalize the billing information and 
terms of the bond instantaneously. For example, a customer may have an account 
with the agent or the underwriter wherein the customer is automatically charged 
10 and an invoice sent, or his or her account can be debited the amount needed for 

the premium. 

Since the completed underwriting forms are stored on the system, an agent 
can search within the system 10 to find policies which have been issued for 
particular customers, for example. This is shown in the sample menu screen 

15 shown in Figure 2. An agent can search for a complete list of bonds which have 

been written by a particular bonding agency, such as the assignee of the present 
invention, i.e. POBS. Alternatively, the agent can search by a particular bond 
number to search for that specific bond, by the customer name, as well as other 
basic information such as the effective date of the bond or the state in which it 

20 was issued. 

Therefore, according to the present invention, an insurance agent can 
quickly and easily provide surety bonds and fidelity policies to his customers 
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without having to perform a tedious search for the exact form necessary for that 
client, while also advantageously eliminating the repetitive information gathering 
process. 

The above steps are shown in a more simplified detail in the flow chart 
5 shown in Figure 21. Once an agent enters 1010 the system 10 using the user 

interface layer 100 for example, the system 10 inquires if a bond has previously 
been issued for a particular customer 1020. If yes, the database 420 can be 
searched 1025 for the basic information about that customer which can then be 
retrieved, thereby eliminating the need to repeatedly enter the customer 

10 information which also reduces the potential for error. Once the customer 

information is recovered 1025 or otherwise entered 1030, the type of underwriting 
instrument and the necessary bond form is automatically selected 1040 based 
thereupon. The agent then enters 1060 other basic information such as contract 
price and contract completion date if a surety bond is being quoted for example. 

15 When this basic information such as the location of the contract or facility where 

the fidelity policy is to be issued is entered, the system 10 retrieves 1070 from the 
database library 420 bond rates which have been established for appropriate 
geographic areas, e.g. each of the fifty states by zip code. In the next step of the 
process, the premium is calculated 1050 for that policy, as well as the amount of 

20 commission to be paid to the agent 1 120 using the ratings calculation engine 340. 

Once the bond has been finalized and issued, an invoice is submitted to the 
customer 1130 and/or a credit or debit notice is sent 1140 to the agency's 
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accounting system. After payment has been received electronically for the bond, 
the bond itself is created 1 150 and appropriate supporting documentation, such as 
a Power of Attorney, are created 1 160 such that they are ready for execution by 
the insurance customer. 

5 Thus, the present invention allows an agent to provide an instant quote on 

the cost of a fidelity policy or surety bond, while providing a preselected list of 
coverages normally needed for these types of policies. The system 10 provides 
for instantaneous issuance and execution of the bond and for the miscellaneous 
form processing that must be done for each bond, which heretofore had to be done 

10 manually. Therefore the present invention allows an agent to price, issue and 

manage its fidelity insurance and surety bond business in a more efficient manner. 

Thus, by using a personal computer or other suitable microprocessor based 
device 110 in connection over a telecommunication network such as the Internet, 
an agent can connect to the data processing system 200, 300, 400 (website) for 

15 issuing any of a variety of fidelity policies or surety bonds to a customer. The 

website 200, 300, 400 includes processing abilities necessary for pulling desired 
forms from the library database 420 stored in the database management layer 400. 
The agent need only input the data with his or her keyboard or other information 
input means such as by clicking on different informational categories with a 

20 mouse, which information pertains to that client. For example, if client basic 

information is already stored in the database 40, an agent need only to click on the 
client's name, and relevant information about that client can be automatically 
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pulled from the database management layer 400. The agent then need only input 
the specific information regarding a contract for which the surety bond is to be a 
guarantee, or the type of business that is to be insured by the fidelity policy. The 
system 1 0 then calculates the premium payment for that underwriting instrument 
5 based on the client data and the contract or business data, and thereby processes 

this information to issue the bond policy, which policy is then also stored on the 
website 200, 300, 400. 

While specific embodiments of the invention have been described in 
detail, it will be appreciated by those skilled in the art that various modifications 
10 and alterations would be developed in the overall teachings of the disclosures. 

Accordingly, the particular arrangement discloses are meant to be illustrative only 
and not limited as to the scope of the invention which is to be given the full 
breadth of the appended claims and in any and all equivalents thereof. 
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